home *** CD-ROM | disk | FTP | other *** search
- > I have recently read RFC 1203 (2/91). A question occurred
- > me when I saw the following sentence (page 3): "This should allow
- > the IMAP protocol to evolve away from its current reliance on RFC822".
-
- > Is there any work being done in order to support other
- > message types (for example, X.400 P2(84) or P2(88)) ?
-
- Yes, if you count the addition of structure decomposition aligned with MIME. I
- know of no plans or intentions to support X.400 P2 or P22 constructs in the
- protocol, however. Mark?
-
- The real advantage of adding structuring support to the protocol is that then
- you don't have to do it all in every client. Clients can use the server to
- parse and obtain whatever parts of each message they want. This is true even
- when you use a disconnectable client -- the client can store the message in
- whatever format it likes.
-
- > I suppose
- > this could be interesting since the same UA could be used for the
- > following configurations:
-
- > ...
-
- > This configuration would allow the UA to receive RFC822 and
- > P2 messages without any conversions to be applied.
-
- While there might be some advantage here, it is not likely to amount to much.
- Any conversion of X.400 to MIME should involve no loss of semantics at all.
- (The same cannot be said for the other direction, unfortunately.)
-
- Remember that one goal of IMAP is to keep the clients small and simple. Having
- support for two message formats and structures, no matter what formats you
- pick, increases the size of the clients considerably. It would be far better to
- do the conversion to MIME format and structure on the server host. In the case
- of X.400->MIME this can be done quite efficiently on a server -- I know because
- I've written code to do it myself.
-
- Ned
-
-
-